1. Field of the Invention
The present invention relates to telephony and the internet and, more specifically, to a telephone internet service that notifies an internet user of an incoming telephone call and provides the user with the option of receiving the telephone call while still maintaining an internet connection.
2. Background of the Invention
The most common method of internet access by individual and small business subscribers is by computer modem over conventional analog telephone lines. Subscribers connect to internet service providers (ISPs) by dialing access numbers from within communications applications. Once connected to the ISP, subscribers use internet applications, e.g., web browsers, to exchange data with the internet and browse the web.
While connected to the internet, the conventional analog telephone line is dedicated to data exchange between the subscriber""s personal computer (PC) and the internet service provider, and as a result, cannot receive any telephone calls. Thus, when the telephone line is being used for internet access, the subscriber frequently misses incoming telephone calls. Several solutions have been proposed to alleviate this problem. However, each falls short of a complete solution.
One solution is to add another telephone line so that one line is dedicated to telephone calls and another line is dedicated to internet access. However, this solution burdens subscribers with the additional costs of another telephone line. In many cases, the relatively short amount of time spent on the internet by the average subscriber does not justify the installation and monthly service costs associated with a second telephone line.
In response to this service gap, telephony providers have turned to internet call waiting services to notify internet users of incoming telephone calls. Internet call waiting services enable subscribers to receive traditional telephone calls while connected to the internet through a single telephone line. These services send an incoming call message detailing calling party information through a pop-up window on the subscriber""s computer screen. In response to this message, a subscriber can accept the call, route the call to voice mail, redirect the call to another number, play a message to the caller, or simply ignore the call. If the subscriber accepts the call, the internet call waiting service terminates the internet connection and connects the call to the user""s regular telephone. However, subscribers still do not have the ability to use a single telephone line to simultaneously carry on a voice conversation and continue using the internet.
In response to the drawbacks of internet call waiting services, Internet Protocol (IP) telephony service providers, e.g., eFusion, Inc., have developed internet call waiting services that support a conventional public switched telephone network (PSTN) call during an internet session on one telephone line. These services are typically referred to as internet call waiting with voice over internet protocol (ICW-VOIP) services. With this type of service, an internet subscriber can accept an incoming call, carry on a conversation as part of the call, and continue to browse the web during the call. Incoming PSTN calls are forwarded to application gateways that complete the calls through internet connections to the subscriber""s personal computer. In addition, subscribers can place outbound calls during an internet session to a conventional PSTN telephone number, complete with Dual Tone Multi-frequency tone generation. The subscriber communicates over the internet to the application gateway, which completes the call using the PSTN.
Although ICW-VOIP services have partially addressed the problems associated with simultaneous telephone calls and internet sessions, these systems fail to efficiently use existing network resources, relying instead on complex software applications layered on top of PSTN and IP network architectures. Such a system is disclosed, for example, in U.S. Pat. No. 5,889,774, which describes an elaborate method of selecting internet/PSTN changeover servers to establish a voice call to a PSTN extension on behalf of a networked client computer. Because these systems must route voice calls through one or more changeover servers to maintain an initial internet connection, the systems suffer from reduced transmission speed, quality, reliability, and security. In packet-switched voice communication, these transmission deficiencies result in perceptible delays and breaks in conversation.
ICW-VOIP service providers have relied on software because of the inability of gateways to support PSTN-to-IP mapping. For example, H.323 gateways are not capable of completing connections between PSTN telephones and personal computers, and do not have standardized interfaces for querying external databases. (The term xe2x80x9cH.323xe2x80x9d as used herein refers to the internet telephony standard for real-time multimedia communications for packet-based networks with which components and communications must comply.) Typically, these types of gateways are engineered specifically for gateway-to-gateway long distance bypass calls, in which subscribers avoid long distance toll charges by routing voice communication over the packet-switched internet. In long distance bypass systems, transmissions are translated between voice circuit-switched and data packet-switched communication at both sides of a communication. The gateways can support IP-to-PSTN communication, PSTN-to-PSTN communication, and IP-to-IP communication, but not PSTN-to-IP. Thus, a gateway cannot receive a PSTN call, map an IP call to the appropriate subscriber, or initiate a call to the subscriber to complete a connection. Some gateways, implemented with different variations of the H.323 protocol, do not even support IP-to-PSTN communication.
In contrast to the inefficient and slow routing of the ICW-VOIP software services and the lack of intelligent functionality of the gateways, PSTN Advanced Intelligent Networks (AINs) offer the ability to quickly route calls and terminate connections based on subscriber information. AIN networks use a complex, high speed, high traffic volume data packet-switched messaging system to provide versatility in the handling of telephone calls. The Advanced Intelligent Network System is described in U.S. Pat. Nos. 5,701,301 and 5,838,774, which are hereby incorporated by reference.
The AIN enables telecommunications call control and database access from any computer or switching system connected to the Signaling System 7 (SS7) network. The Signaling System 7 (SS7) network refers to the current implementation of the Common Channeling Interoffice Signaling control network used in the United States. The Advanced Intelligent Network (AIN) is a standard call control protocol that uses the SS7 network for message transport.
AIN infrastructures of the PSTN include service switching points (SSPs), service nodes (SNs), signal transfer points (STPs), and signal control points (SCPs) with databases. An example of a local PSTN structure 102 is shown in FIG. 1a. The signal control point is a computer that holds, accesses, and maintains the database and communicates with the SSP in directing call routing. The database stores subscriber-specific information used by the network to route calls. The SSP communicates with the SCP and queries the SCP for subscriber-specific instructions as to how calls should be completed. The signal transfer point is a packet switch that shuttles messages between the signal control point and the signal service point. The service node is a smart termination that can assess incoming call information and make appropriate connections.
Much of the intelligence and the basis for many of the new enhanced features of the network reside in the local service control point (SCP). As known by those skilled in the art, service control points are physically implemented by relatively powerful fault tolerant computers. Typical implementation devices include the Star Server FT Model 3200 and the Star Server FT Model 3300, both available from Lucent Technologies(trademark). The architecture of these computers is based on Tandem Integrity S2 and Integrity S1 platforms, respectively. In most implementations of a public switched telephone network, service control points are also provided in redundant mated pairs to ensure network reliability.
The service control points maintain the network databases used in providing custom services, such as databases that identify customers requiring particular services. To keep the processing of data and calls as simple and as generic as possible at switches, triggers are defined at the switches for each call. Each trigger is assigned to a particular subscriber line or call, and prompts a query to a service control point. The service control point then checks its database to determine whether a customized calling feature or custom service should be implemented for this particular call, or whether conventional plain dialed-up telephone service (POTS) should be provided for the call. The results of the data base inquiry are sent back to the switch from the SCP. The return message includes instructions to the switch as to how to process the call. The instruction may be to take some special action as a result of a customized calling service or custom feature. If a xe2x80x9ccontinuexe2x80x9d message is received at the switch from the SCP, the call is treated as a POTS-type call. The switch will then move through its call states, select the call digits, and may generate further messages that will be used to set up and route the call, as described above.
Despite the benefits of advanced call routing capabilities, AIN networks are limited by the Signaling System 7 communication in their ability to exchange data with other networks, such as the internet. Thus, the benefits of the specialized AIN services have necessarily been confined to the PSTN infrastructure. However, as the internet has expanded and the demand for subscriber access has grown, the need for a capable interface between the IP network and the PSTN infrastructure has become increasingly important. Thus, the inability of conventional systems to seamlessly exchange data across the IP and PSTN networks limits the potential services available to subscribers.
Therefore, there remains a need for a combined IP and PSTN architecture that enables communication between IP and PSTN protocol. Within this architecture, there remains a need for an ICW-VOIP service that avoids the complicated software solutions of the prior art, compensates for the limited communication capabilities of gateways, and provides fast, reliable, and secured voice communication. This service should eliminate the complex process of selecting and engaging internet/PSTN changeover servers and, instead, should take advantage of existing reliable telephone network resources to provide single-line subscribers with the convenience of answering telephone calls while still maintaining internet access. Furthermore, this service should be easily adaptable to accommodate future advances in gateway technology and compatibility.
The present invention is an Internet Call Waiting-Voice over Internet Protocol network architecture that uses an Advanced Intelligent Network to seamlessly merge local PSTN service with internet systems. The invention facilitates PSTN-to-IP calls using VOIP and existing telephone network resources. Using the fast, reliable, and secured PSTN infrastructure, the present invention enables ICW subscribers to answer telephone calls during internet sessions without having to disconnect internet access.
The present invention is an IP/PSTN architecture in which an SCP functions as a gatekeeper, an H.323 gateway functions as a protocol translator, and an SN functions as a bridge that connects calls. As the gatekeeper, the SCP stores subscriber information, maps calls based on the subscriber information, and issues instructions directing calls between the IP and PSTN networks. As the protocol translator, the H.323 gateway receives an H.323 call initiated from the subscriber""s PC, translates the H.323 (IP) call to a PSTN call, and forwards the PSTN call to the SN. As the bridge, the SN receives calls from the H.323 gateway and PSTN caller (i.e., from the IP and PSTN sides of the network), matches the calls based on the instructions from the SCP and the called party number of each call, and bridges the calls to enable PSTN-to-IP communication and ICW-VOIP.
To initiate internet access, a subscriber dials a public feature code, e.g., *28, followed by the telephone number of the subscriber""s ISP. The public feature code activates a trigger provisioned on the subscriber""s telephone line. Upon receiving the public feature code, the subscriber""s SSP sends an event notification query to an SCP, asking for further instruction. The SCP records the subscriber""s calling party number into an SCP call setup table, and instructs the SSP to route the call to the specified ISP number. The SCP then waits for a registration message from the subscriber""s PC.
Once the subscriber""s PC is connected to the internet, the subscriber""s PC sends a registration message to the SCP. (The internet address of the SCP is provisioned on the subscriber""s PC as a part of service initiation.) The registration message includes the telephone number and internet address of the subscriber. Upon receiving the registration message, the SCP matches the subscriber telephone number from the registration message with the subscriber calling party number previously entered into the SCP call setup table, and adds the subscriber""s internet address to the table entry.
With the table entry complete, the SCP provisions a termination attempt trigger on the subscriber""s SSP. The SCP uses this trigger to detect calls to the subscriber""s line. When the subscriber line receives a call, the SSP sends a trigger event notification query to the SCP. Based on information in the trigger event notification query, the SCP instructs the SSP on how to handle the incoming call. After activation of the termination attempt trigger, the SCP sends a registration confirmation message back to the subscriber""s PC. This registration confirmation message includes the internet address of the H.323 gateway, and a user identification and password. Later in the process of the present invention, the subscriber""s PC will need the H.323 gateway internet address and the user identification and password to initiate an H.323 call to the H.323 gateway. At this point, registration of the subscriber""s PC is complete.
When the subscriber""s line receives a call, the subscriber""s SSP sends a termination attempt trigger notification query to the SCP. In response to the notification query, the SCP sends a call notification message through the internet to the subscriber""s PC, informing the subscriber that a call is incoming. Through cooperative software provisioned on the subscriber""s PC and the SCP, the subscriber""s PC displays the call notification message as a xe2x80x9cpop-upxe2x80x9d window during the subscriber""s internet session. This pop-up window displays the caller information and presents the subscriber with call disposition options as described in the next paragraph.
The pop-up window presents the subscriber with the following options: 1) ignore the call; 2) forward the call to voicemail or any other PSTN number; 3) accept the call directly over the PSTN line and terminate the internet connection; 4) maintain the internet connection and accept the call through the computer using VOIP; or 5) hold the call until the caller hangs up, or until the subscriber accepts the call over PSTN, accepts the call over VOIP, or forwards the call.
If the subscriber chooses the fourth option, the subscriber""s PC sends an xe2x80x9canswer with VOIPxe2x80x9d message to the SCP, and, in turn, the SCP sends a notification to the SN that a VOIP call bridging will be required. This notification message includes the PSTN caller""s telephone number as the calling party and the subscriber""s telephone number as the called party. The SN enters this notification information into an SN call setup table. After sending the xe2x80x9canswer with VOIPxe2x80x9d message to the SCP, the subscriber""s PC immediately initiates a H.323 call to the H.323 gateway using the H.323 gateway internet address and the user identification and password received in the registration confirmation message.
Upon receiving the H.323 call from the subscriber""s PC, the H.323 gateway converts the H.323 call into a PSTN call and routes the PSTN call to the SN for call bridging. To accomplish this call routing, the present invention uses a double-triggering mechanism, which activates, for a second time, the termination attempt trigger previously provisioned on the subscriber""s line. In this manner, the H.323 gateway calls the subscriber phone number to route the PSTN call to the SN. Because the termination attempt trigger is still provisioned on the subscriber line, the subscriber""s SSP sends another termination attempt trigger notification query to the SCP when the subscriber""s SSP receives the call from the H.323 gateway.
Recognizing from the calling party number that the PSTN call is from the H.323 gateway, the SCP issues a routing instruction to the SSP that replaces the calling party number with the subscriber""s phone number and replaces the called party number with the number of a multi-line hunt group (MLHG) pre-provisioned on the SN. (Two MLHG numbers are pre-provisioned on the SN for the present invention: one number is for calls from the H.323 gateway and the other number is for calls from PSTN callers.) Based on the SCP instructions, the SSP routes the PSTN call from the H.323 gateway to the gateway MLHG on the SN.
When the SN receives the PSTN call from the H.323 gateway, the SN checks the calling party number of the call against the SN call setup table. If the SN finds a match between the calling party number of the call and a subscriber number in the call setup table, the SN sends an H.323 gateway call arrival confirmation message to the SCP. Then, the SN waits for the arrival of the call from the PSTN caller for the call bridging.
When the SCP receives the H.323 gateway call arrival confirmation from the SN, the SCP instructs the SSP to forward the call from the PSTN caller to the MLHG number provisioned on the SN for calls from PSTN callers. The SCP waits for a call connection confirmation message from the SN.
When the SN receives the PSTN caller""s call, the SN checks the calling party number of the call. If the SN finds a match between the calling party number of the call and a PSTN caller number in the SN call setup table, the SN connects a port of the gateway MLHG to a port of the PSTN MLHG, thereby connecting the PSTN call to the gateway call from the subscriber PC. Once connected, the SN sends a call connection notification back to the SCP. At this point, the call bridging is complete. The H.323 call from the subscriber""s PC to the H.323 gateway represents the IP portion of the call, while the PSTN portion of the call is from the H.323 gateway to the SSP, from the SSP to the SN, from the SN back to the SSP, and from the SSP to the PSTN caller. The functions of the SN and its MLHGs are discussed in more detail below in xe2x80x9cDetailed Description of the Invention.xe2x80x9d
Once the connection is established, the subscriber can conduct voice communication over the internet while continuing to browse the web. The SN maintains the connection between the subscriber and PSTN caller to keep the SCP in control of the routing so that the call can be disconnected and forwarded to another number or reverted back to the subscriber""s PSTN line should the subscriber choose to do so. If the subscriber chooses to forward the call and the call is not answered, the call is reconnected to the subscriber for additional VOIP conversation and the SCP and SN wait for further direction from the subscriber.
In the ICW-VOIP architecture of the present invention, the SN compensates for the limited capabilities of currently available gateways, i.e., the gateways that do not support PSTN-to-IP communication. However, in the event that gateway technology advances to satisfy this need, the present invention is easily adaptable to new hardware options. In a preferred embodiment of the present invention, in which the gateway acquires the capabilities and functions of the SN, the gateway handles PSTN-IP communication, supporting the launching of calls through the gateway directly to the subscriber. This embodiment eliminates the need to bridge calls through the SN and still maintains the ability to break, forward, and revert calls.
For simplicity, this specification describes the present invention in terms of a single SSP and a single H.323 gateway. However, as well known by those skilled in the art, the single SSP represents one or more SSPs and the single gateway represents one or more gateways. FIG. 1b illustrates this concept. For capacity and reliability, several H.323 gateways could be connected to several SSPs in a serving area. In this configuration, the SCP would decide which H.323 gateway to use for a particular call and would perform the load balancing among all of the H.323 gateways. The PSTN caller and subscriber could reside on the same SSP or different SSPs. The SSPs could also be located in the same serving area or different serving areas. If the SSPs are located in different serving areas, a trunking connection would be made via SS7 signaling between the PSTN caller""s SSP and the subscriber""s SSP. When the trunking connection is made to the subscriber""s SSP, the termination attempt trigger provisioned on the subscriber""s SSP is sent to the SCP. Thus, it should be understood that the terms xe2x80x9cSSPxe2x80x9d and xe2x80x9cgateway,xe2x80x9d as used in this specification and in the claims, mean one or more SSPs and one or more gateways, respectively.
Accordingly, it is an object of the present invention to provide a fast, reliable, and secured ICW-VOIP service that allows single telephone line subscribers to accept incoming voice calls while continuing to browse the internet.
It is another object of the present invention to provide fast, high-quality ICW-VOIP service that reduces perceptible delays and breaks in voice conversation.
It is another object of the present invention to compensate for a gateway""s inability to map PSTN-to-IP calls and to support PSTN-to-IP communication.
It is another object of the present invention to provide an easily adaptable ICW-VOIP architecture that will accommodate future advances in gateway capabilities.
It is another object of the present invention to merge the IP network with the PSTN infrastructure to enable seamless Signaling System 7 communication between PSTN callers, and internet users.
These and other objects of the present invention are described in greater detail in the detailed description of the invention, the appended drawings, and the attached claims.